This rewrite represents a few years of pain and suffering finally being overcome!

Unfortunately this will be a major API change and the upgrade path is not yet obvious. Considering that 1.x relied so heavily on private APIs I don't know if we can even support a clean upgrade path from Ember < 1.10 apps.

This rewrite will require Ember >= 2.10 positional params bug which wasn't fixed until 2.10 (see: emberjs/ember.js#14533)

The goals for this rewrite are:

1. KISS. 1.x of this library tried to do too much. And from what I can see in the eco system, the addons that have come about to replace 1.x of Easy Form are also doing too much. This leads to bloat of the libraries and means the complexity to maintain is high. Instead 2.x and moving forward will keep as simple as possible.
2. No dependencies. There won't be any 3rd party dependencies that will be required to build a form. Instead you can opt-in to using other libraries, for example if you wanted to replace f.submit with an ember-async-button we'll support an API to add f.async-submit or something like that. Want to use ember-power-select? Great, an API hook will be provided and now you'll have {{f.power-select "country" options=countries}}
3. Use HTML Constraint Validations. The HTML5 Validation API has come a long way since 1.x of this library. Back then there was good reason to work around it to provide the desired UX for form validation display and correction. Today getting that experience correct between desktop and mobile (without even considering other platforms) is difficult. Let's avoid the conversation all together and just rely on the browser to display our validation messages instead. We'll lean on the Custom Constraint API for setting the validation messages. However, we will not rely on the inline constraints such as required, pattern, etc... as we still believe that the validations should be represented in the data model and not in the form. This will reduce a lot of code and solve a lot of bikeshedding around how best to display errors. Styling will required eval of the constraint psuedo classes as well as any other custom styling the browser permits. This library will not attempt to apply classes or states to the controls for validation state.
4. Highly customizable. Templates and components should be easily overridden to provide points of customization for consuming apps. This library should serve only as a starting point with some common sense APIs for a much larger and complex form implementation that is required of the consuming app. This would also provide 3rd party libraries to give out of the box styling from grid frameworks or other custom styling packages.

As a note, credit should be given to @martndemus's ember-form-for as I believe it is currently the most complete solution in the market. There are some philosophical differences that motivated me to resurrect easy-form over contributing to form-for, but for many use-cases form-for should be a great solution. It is still not clear if 2.x of easy-form is a good idea and this PR should, for the time being, be seen as a complete experimental branch and not relied upon for anyone's app until otherwise stated.